Revision: file-utils--devo--1.0--patch-115
Archive: lord@emf.net--2003
Creator: Tom Lord <lord@emf.net>
Date: Fri May 23 13:27:57 PDT 2003
Standard-date: 2003-05-23 20:27:57 GMT
Summary: [case-22] fixed apply_changeset tree-delta bug
Keywords: 
New-files: {arch}/file-utils/file-utils--devo/file-utils--devo--1.0/lord@emf.net--2003/patch-log/patch-115
Modified-files: =THANKS ChangeLog libarch/apply-changeset.c
New-patches: lord@emf.net--2003/file-utils--devo--1.0--patch-115


When removing a directory (temporarily or permanently) from 
the target tree, a running-inventory of the tree is updated,
and a "set aside with" list is updated.

The "set aside with" list is all the nested components lost
along with the directory so that, if the dir is later added back
at a new location, all those nested components are added back
to the running inventory as well.   

The set aside with list was computed slightly incorrectly.  If a
deeply nested dir was set aside, it's nested components were correctly
recorded as set aside, but then if a parent dir of that was also set
aside, the deeply nested components were redundantly recorded as set
aside.  

In the case where the parent dir is then put back into the tree in a
deeper location than the formerly deeper dir winds up at, the running
total ultimately winds up erroneously thinking that some of the
formerly deeply nested contents are now deeply nested under the new
location of the old parent dir.  In other words:

   ORIG			MOD
      .                         .
       \                       / \
	A		      B   X
	 \                   /     \
	  B                 c       A
	   \
            c

After inserting A, the running inventory _thought_ the tree looked
like:

                 .
		/ \
               B   X
                    \
                     A
                      \
                       B
                        \
                         c


(This running inventory, btw, is the number one reason why it's easier
to write apply_changeset in C than sh.  If standard sh had (fast)
associative tables, it would be a different story.)
